A Framework for Creating Natural Language User Interfaces 
for Action-Based Applications* 

■ Stephen Chong Riccardo Pucella 

O . Cornell University Cornell University 

^ ; Ithaca, NY 14853 USA Ithaca, NY 14853 USA 

Q ■ schong@cs.cornell.edu riccardo@cs.cornell.edu 

Q 



U 



Abstract 

In this paper we present a framework for creating natural language interfaces to action-based 
applications. Our framework uses a number of reusable application-independent components, 
in order to reduce the effort of creating a natural language interface for a given application. 
C/3 , Using a type-logical grammar, we first translate natural language sentences into expressions 

^ ' in an extended higher-order logic. These expressions can be seen as executable specifications 

corresponding to the original sentences. The executable specifications are then interpreted by 
invoking appropriate procedures provided by the application for which a natural language in- 
, terface is being created. 

^ ■ 1 Introduction 

^ ■ The separation of the user interface from the application is regarded as a sound design principle. A 

. clean separation of these components allows different user interfaces such as GUI, command-line 

Q I and voice-recognition interfaces. To support this feature, an application would supply an applica- 

tion interface. Roughly speaking, an application interface is a set of "hooks" that an application 
provides so that user interfaces can access the application's functionality. A user interface issues 
commands and queries to the application through the application interface; the application executes 
\ these commands and queries, and returns the results back to the user interface. We are interested 

in applications whose interface can be described in terms of actions that modify the application's 
state, and predicates that query the current state of the application. We refer to such applications as 
action-based applications. 

In this paper, we propose a framework for creating natural language user interfaces to action- 
based applications. These user interfaces will accept commands from the user in the form of natural 
language sentences. We do not address how the user inputs these sentences (by typing, by speak- 
ing into a voice recognizer, etc), but rather focus on what to do with those sentences. Intuitively, 
we translate natural language sentences into appropriate calls to procedures available through the 
application interface. 

*A preliminary version of this paper appeared in the Proceedings of the Third International AMAST Workshop on 
Algebraic Methods in Language Processing, TWLT Report 21, pp. 83-98, 2003. 
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Figure 1: Architecture 



As an example, consider the application ToyBlocks. It consists of a graphical representation 
of two blocks on a table, that can be moved, and put one on top of the other. We would like to be 
able to take a sentence such as move block one on block two, and have it translated into suitable calls 
to the ToyBlocks interface that would move block 1 on top of block 2. (This requires that the 
interface of ToyBlocks supplies a procedure for moving blocks.) While this example is simple, 
it already exposes most of the issues with which our framework must deal. 

Our framework architecture is sketched in Figure 1. The diagram shows an application with 
several different user interfaces. The box labeled "NLUI" represents the natural language user in- 
terface that our framework is designed to implement. Our framework is appropriate for applications 
that provide a suitable application interface, which is described in Section 2. We expect that most 
existent applications will not provide an interface conforming to our requirements. Thus, an adapter 
might be required, as shown in the figure. Other user interfaces can also build on this application 
interface. The user interface labeled "Other UI 1" (for instance, a command-line interface) does just 
that. The application may have some user interfaces that interact with the application through other 
means, such as the user interface "Other UI 2" (for instance, the native graphical interface of the 
application). 

The translation from natural language sentences to application interface calls is achieved in 
two steps. The first step is to use a categorial grammar [Carpenter 1997] to derive an intermediate 
representation of the semantics of the input sentence. An interesting feature of categorial grammars 
is that the semantics of the sentence is compositionally derived from the meaning of the words in 
the lexicon. The derived meaning is a formula of higher-order logic [Andrews 1986]. The key 
observation is that such a formula can be seen as an executable specification. More precisely, it 
corresponds to an expression of a simply-typed A-calculus [Barendregt 1981]. The second step 
of our translation is to execute this A-calculus expression via calls to procedures supplied by the 
application interface. 

We implement the above scheme as follows. A parser accepts a natural language sentence from 
the user, and attempts to parse it using the categorial grammar rules and the vocabulary from the 
application-specific lexicon. The parser fails if it is not able to provide a unique unambiguous 
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parsing of the sentence. Successful parsing results in a formula in our higher-order logic, which 
corresponds to an expression in an action calculus — a A-calculus equipped with a notion of action. 
This expression is passed to the action calculus interpreter, which "executes" the expression by 
making appropriate calls to the application via the application interface. The interpreter may report 
back to the screen the results of executing the actions. 

The main advantage of our approach is its modularity. This architecture contains only a few 
application-specific components, and has a number of reusable components. More precisely, the 
categorial grammar parser and the action calculus interpreter are generic and reusable across differ- 
ent applications. The lexicon, on the other hand, provides an application-specific vocabulary, and 
describes the semantics of the vocabulary in terms of a specific application interface. 

In Section 2 we describe our requirements for action-based applications. We define the notion 
of an application interface, and provide a semantics for such an interface in terms of a model of the 
apphcation. In Section 3 we present an action calculus that can be used to capture the meaning of 
imperative natural language sentences. The semantics of this action calculus are given in terms of 
an action-based application interface and application model; these semantics permit us to evaluate 
expressions of the action calculus by making calls to the application interface. Section 4 provides 
a brief introduction to categorial grammars. Section 5 shows how these components (action-based 
appUcations, action calculus, and categorial grammar) are used in our framework. We discuss some 
extensions to the framework in Section 6, and conclude in Section 7. 

2 Action-Based Applications 

Our framework applies to appUcations that provide a suitable Apphcation Programmer Interface 
(API). Roughly speaking, such an interface provides procedures that are callable from external 
processes to "drive" the application. In this section, we describe in detail the kind of interface 
needed by our approach. We also introduce a model of applications that will let us reason about the 
suitabiUty of the whole framework. 

2.1 Application Interface 

Our framework requires action-based applications to have an application interface that specifies 
which externally callable procedures exist in the application. This interface is meant to specify 
procedures that can be called from programs written in fairly arbitrary programming languages. To 
achieve this, we assume only that the calling language can distinguish between objects (the term 
'object' is used is a nontechnical sense, to denote arbitrary data values), and Boolean values ft (true) 
and jf (false). 

An application interface specifies the existence of a number of different kind of procedures. 

(1) Constants: There is a set of constants representing objects of interest. For ToyBlocks, the 
constants are bl, b2, and table. 

(2) Predicates: There is a set of predicates defined over the states of the application. A predicate 
can be used to check whether objects satisfy certain properties, dependent on the state of 
the application. Predicates return truth values. For ToyB locks, we consider the single 
predicate is_on(6Z, pos), that checks whether a particular block bl is in a particular position 
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pos (on another block or on the table). Each predicate p has an associated arity, indicating 
how many arguments it needs. 

(3) Actions: Finally, there is a set of actions defined by the application. Actions essentially effect 

a state change. Actions can be given arguments, for example, to effect a change to a particular 
object. For ToyBlocks, we consider a single action, move(&Z, pos), which moves block 
hi to position pos (on another block or on the table). As with predicates, each action has an 
associated arity, which may be 0, indicating that the action is parameterless. 

We emphasize that the application interface simply gives the names of the procedures that are 
callable by external processes. It does not actually define an implementation for these procedures. 

In order to prevent predicates and actions from being given inappropriate arguments, we need 
some information about the actual kind of objects associated with constants, and that the predicates 
and actions take as arguments. We make the assumption that every object in the application belongs 
to at least one of many classes of objects. Let C be such a set of classes. Although this termi- 
nology evokes object-oriented programming, we emphasize that an object-oriented approach is not 
necessary for such interfaces; a number of languages and paradigms are suitable for implementing 
appHcation interfaces. 

We associate "class information" to every name in the interface via a map a. More specifically, 
we associate with every constant c a set o-(c) C C representing the classes of objects that can be 
associated with c. We associate with each predicate p a set a{p) C C" (where n is the arity of the 
predicate), indicating for which classes of objects the predicate is defined. Similarly, we associate 
with each action a a set a {a) C (again, where n is the arity of the action, which in this case can 
be 0). As we will make clear shortly, we only require that the apphcation return meaningful values 
for objects of the right classes. 

Formally, an application interface is a tuple / = (C, P, A, C, a), where C is a set of constant 
names, i-* is a set of predicate names, ^4 is a set of action names, C is the set of classes of the 
application, and a is the map associating every element of the interface with its corresponding class 
information. The procedures in the interface provide a means for an external process to access 
the functionality of the apphcation, by presenting to the language a generally accessible version 
of the constants, predicates, and actions. Of course, in our case, we are not interested in having 
arbitrary processes invoking procedures in the interface, but specifically an interpreter that interprets 
commands written in a natural language. 

In a precise sense, the map a describes typing information for the elements of the interface. 
However, because we do not want to impose a particular type system on the application (for instance, 
we do not want to assume that the application is object-oriented), we instead assume a form of 
dynamic typing. More precisely, we assume that there is a way to check if an object belongs to 
a given class. This can either be performed through special guard predicates in the application 
interface (for instance, a procedure is_bIock that returns true if the supplied object is actually a 
block), or a mechanism similar to Java's instanceOf operator. 

Example 2.1. As an example, consider the following interface It for ToyBlocks. Let It = 
(C, P, A, C, a), where, as we discussed earher, 

C = {bl,b2, table} 

P = {is_on} 
A = {move}. 
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We consider only two classes of objects, block, representing the blocks that can be moved, and 
position, representing locations where blocks can be located. Therefore, C = {block, position}. 

To define a, consider the way in which the interface could be used. The constant bl represents an 
object that is both a block that can be moved, and a position to which the other block can be moved 
to (since we can stack blocks on top of each other). The constant b2 is similar. The constant table 
represents an object that is a position only. Therefore, we have: 

C7(bl) = {block , position} 
o"(b2) = {block, position} 
o"(table) = {position}. 

Correspondingly, we can derive the class information for is_on and move: 

(T(is_on) = {{block, position)} 
(7(move) = {{block , position)} . 

□ 

2.2 Application Model 

In order to reason formally about the interface, we provide a semantics to the procedures in the 
interface. This is done by supplying a model of the underlying application. We make a number of 
simplifying assumptions about the application model, and discuss relaxing some of these assump- 
tions in Section 6. 

AppUcations are modeled using four components: 

(1) Interface: The interface, as we saw in the previous section, specifies the procedures that can 
be used to query and affect the application. The interface also defines the set C of classes of 
objects in the appUcation. 

(2) States: A state is, roughly speaking, everything that is relevant to understand how the apph- 
cation behaves. At any given point in time, the application is in some state. We assume that 
an application's state changes only through explicit actions. 

(3) Objects: This defines the set of objects that can be manipulated, or queried, in the application. 
As we akeady mentioned, we use the term 'object' in the generic sense, without implying 
that the application is implemented through an object-oriented language. Every object is 
associated with at least one class. 

(4) Interpretation: An interpretation associates with every element of the interface a "meaning" 
in the application model. As we shall see, it associates with every constant an object of 
the model, with every predicate a predicate on the model, and with every action a state- 
transformation on the model. 

Formally, an application is a tuple M = {I,S, 0,7r), where I in an interface (that defines the 
constants, predicates, and actions of the application, as well as the classes of the objects), S is the 
set of states of the application, O is the set of objects, and tt is the interpretation. 
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We extend the map a defined in the interface to also provide class information for the objects 
in O. Specifically, we define for every object o € O a set a{o) C C of classes to which that object 
belongs. An object can belong to more than one class. 

The map tt associates with every state and every element in the interface (i.e., every constant, 
predicate and action) the appropriate interpretation of that element at that state. Specifically, for a 
state s G 5, we have 7r(s)(c) G O. Therefore, constants can denote different objects at different 
states of the applications. For predicates, 7r(s)(p) is a partial function from O x . . . x O to truth 
values it or ff. This means that predicates are pure, in that they do not modify the state of an 
application; they are simply used to query the state. For actions, 7r(s)(a) is a partial function from 
O X . . . X O to <S. The interpretation vr is subject to the following conditions. For a given predicate p, 
the interpretation tt{s){p) must be defined on objects of the appropriate class. Thus, the domain of 
the partial function 7r(s)(p) must at least consist of {(oi, . . . , o„) | a{oi) x . . . xa{on)r\a{p) ^ 0}. 
Similarly, for a given action a, the domain of the partial function 7r(s)(a) must at least consist of 
{(oi, . . . , On) I o'(oi) X ... X a{on)r\(T{a) / 0}. Furthermore, any class associated with a constant 
must also be associated with the corresponding object. In other words, for all constants c, we must 
have a{c) C c7(7r(s)(c)) for all states s. 

Example 2.2. We give a model Mt for our sample ToyBlocks application, to go with the inter- 
face It defined in Example 2.1. Let Mt = {It, S, O, vr). We will consider only three states in the 
application, S = {si, S2, S3}, which can be described variously: 

in state si, blocks 1 and 2 are on the table 

in state S2, block 1 is on block 2, and block 2 is on the table 

in state S3, block 1 is on the table, and block 2 is on block 1 . 

We consider only three objects in the model, O = {bi,b2,t}, where 61 is block 1, 62 is block 2, and 
t is the table. We extend the map a in the obvious way: 

(t(6i) = {block , position} 
c(^2) = {block , position} 
a{t) = {position}. 

The interpretation for constants is particularly simple, as the interpretation is in fact independent of 
the state (in other words, the constants refer to the same objects at all states): 



7r(s)(bl) = bi 
7r(s)(b2) = 62 
7r(s) (table) = t. 



The interpretation of the is_on predicates is straightforward: 




The interpretation of move is also straightforward: 
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7r(si)(move)(x) 

7r(s2)(move)(x) 
7r(s3)(move)(x) 



' S2 if X = (61,62) 

S3 ifx= (62,61) 

_ si if X € {(61, 0,(61, 61), (62, 0,(62, 62)} 

si if X = (61, t) 

52 ifx G {(61, 61), (61, 62), (62, 0,(62, 61), (62, 62)} 
si if X = (62,0 

53 ifx G {(61, 0,(61, 61), (61, 62), (62, 61), (62, 62)}. 



If a block is unmovable (that is, if there is another block on it), then the state does not change 
following a move operation. □ 



3 An Action Calculus 

Action-based application interfaces are designed to provide a means for external processes to access 
the functionality of an appUcation. In this section we define a powerful and flexible language that 
can be interpreted as calls to an application interface. The language we use is a simply-typed A- 
calculus extended with a notion of action. It is effectively a computational A-calculus in the style 
of Moggi [1989], although we give a nonstandard presentation in order to simpUfy expressing the 
language semantics in terms of an apphcation interface. 

The calculus is parameterized by a particular application interface and application model. The 
application interface provides the primitive constants, predicates, and actions, that can be used to 
build more complicated expressions, while the application model is used to define the semantics. 



3.1 Syntax 

Every expression in the language is given a type, intuitively describing the kind of values that the 
expression produces. The types used in this language are given by the following grammar. 

Types: 

type 

object 
boolean 

action 
function 



The types r correspond closely to the types required by the action-based application interfaces we 
defined in the previous section: the type Bool is the type of truth values, with constants true and 
false corresponding to the Boolean values it and jf, and the type Obj is the type of generic objects. 
The type Act is more subtle; an expression of type Act represents an action that can be executed to 
change the state of the application. This is an example of computational type as defined by Moggi 
[1989]. As we shall see shortly, expressions of type Act can be interpreted as calls to the action 
procedures of the apphcation interface. 

The classes C defined by the application interface have no corresponding types in this language — 
instead, all objects have the type Obj. Incorporating these classes as types is an obvious possible 
extension (see Section 6). 

The syntax of the language is a straightforward extension of that of the A-calculus. 



Obj 

Bool 
Act 

Tl T2 
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Syntax of Expressions: 



V ::= 



value 



true I false 

\x:T.e 
skip 



null action 
expression 



boolean 
function 



e ::= 



X 



V 



variable 
value 



idcO 



constant 

predicate 

action 

application 

conditional 

action sequencing 



idp{ei, . 
ida{ei,. 

ei 62 




61:62:63 



ei;e2 



The expressions idc{), idp{ei, . . . , e^) and ida{ei, . . . , e^) correspond to the procedures (respec- 
tively, constants, predicates, and actions) available in the application interface. (Constants are writ- 
ten idc{) as a visual reminder that they are essentially functions: idc{) may yield different values at 
different states, as the semantics will make clear.) So, for ToyBlocks, the constants are bl, b2, 
and table; the only predicate is is_on; and the only action is move. The expression ei 762:63 is a 
conditional expression, evaluating to 62 if 61 evaluates to true, and 63 if ei evaluates to false. The 
expression ei; 62 (when ei and 62 are actions) evaluates to an action corresponding to performing 
ei followed by 62. The constant skip represents an action that has no effect. 

Example 3.1. Consider the interface for ToyBlocks. The expression bl() represents block 1, 
while table() represents the table. The expression move(bl(), table()) represents the action 
of moving block 1 on the table. Similarly, the action move(bl(), table()); move(b2(), bl()) 
represents the composite action of moving block 1 on the table, and then moving block 2 on top of 
block 1. □ 

3.2 Operational Semantics 

The operational semantics is defined with respect to the application model. More precisely, the 
semantics is given by a transition relation, written (s, e) — > {s', e'), where s, s' wee states of the 
application, and e, e' are expressions. Intuitively, this represents the expression e executing in state 
s, and making a one-step transition to a (possibly different) state .s' and a new expression e'. 

To accommodate the transition relation, we need to extend the syntax of expressions to account 
for object values produced during the evaluation. We also include a special value ★ that represents 
an exception raised by the code. This exception is used to capture various errors that may occur 
during evaluation. 
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Additional Syntax of Expressions: 



Vo & O object value 

V ::= value 

Vo object 
* exception 

The transition relation is parameterized by the functions Sc, Sp and 5p, given below. These 
functions provide a semantics to the constant, predicate, and action procedures respectively, and 
are derived from the interpretation tt in the application model. The intuition is that evaluating 
these functions corresponds to making calls to the appropriate procedures on the given application 
interface, and returning the result. 

Reduction Rules for Interface Elements: 

5c{s, idc) = ■K{s){idc) 

Ji (. 4r1 „ ^^AjT^{s){idp){vi,...,Vn) if a{vi) X ... X a{vn) n a{idp) ^ 

Op[s, tap, vi,...,vn) - <^ ^ otherwise 

A „ , A j Tris){ida){vi,...,Vn) if aivi) X ... X a{vn) H a{ida) 7^ 

Oa{s,taa,vi,...,Vr,) - < ^ otherwise 



Note that determining whether or not a primitive throws an exception depends on being able to 
establish the class of an object (via the map a). We can thus ensure that we never call an action or 
predicate procedure on the appUcation interface with inappropriate objects, and so we guarantee a 
kind of dynamic type-safety with respect to the application interface. 

Reduction Rules: 

(Red App 1) (Red App 2) (Red App 3) 

(s,ei) — ^ {s,e[) (s,ei) — > (s,*) 



(5,6162) — ^(s,6i62) (5,6162) — > {s,~k) (s, (Axir.ei) 62) — > {s,ei{x^e2}) 

(Red OCon) (Red PCon 1) 

(s, ej) — > {s, e'j) for some i G [l..n] 



(s, idc{)) — > (s, (5c(s, idc)) (s, idp{. . . , 6,, . . .)) — > (s, idp{. . . , e-, . . .)) 

5p{s,idp,vi,...,Vn) = v 



(Red PCon 2) (Red PCon 3) 

(s,6j) — > (s,*) for some i G [l..n] 



{s,idp{ei,...,en)) — (s,*) {s, idp{vi, . . . ,Vn)) — > {s,v) 

(Red If 1 ) (Red If 2) (Red If 3) 

(s, ei) — > (s, e[) {s, 61) — > {s, -k) 



(s,6i?62:63) — > (s,6i?62:63) (s,6i?e2:63) — > (s,*) (s, v?etrue:efaise) — ^ (s,e„) 
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(Red Seq 1) (Red Seq 2) (Red Seq 3) 

(s,ei) — > {s',e[) 



(s,ei;e2) — > {s' , e[; 62) (s,*;e) — ^ (s,*) (s,skip;e) — > {s,e) 

(Red ACon 1 ) (Red ACon 2) 

(s, ej) — > {s, e'j) for some i G [l..n] (s, e,) — > (s,*) for some ?' G [l..n] 



(s,ida(...,ei,...)) — ^ (s,icia(...,e-,...)) (s, ida(ei, . . . , Cn)) — > 

(Red ACon 3) 

— 1 , . 5ais,ida,Vi,...,Vn) = s' 

[S,uia{Vi,...,Vn)) > {s' , skip) 

(Red ACon 4) 

— — ; — 5a{s,ida,Vi,...,Vn)='k 

[S,uia{Vi,...,Vn)) > {s,*} 

The operational semantics is a combination of call-by-name and call-by-value semantics. The 
language as a whole is evaluated in a call-by-name fashion. In particular, rule (Red App 3) indicates 
that application is call-by-name. Actions, on the other hand, are evaluated under what might be 
called call-by-value, as indicated by rule (Red Seq 1). Roughly, the first term of a sequencing 
operation ei;e2 is fully evaluated before 62 is evaluated. Intuitively, applications are evaluated 
under call-by-name because premature evaluation of actions could lead to action procedures in the 
appUcation interface being called inappropriately. For example, under call-by- value semantics, the 
evaluation of the following expression 

(Ax:Act.false?x:skip) A 

would call the action procedure for A, assuming A is an action in the application interface. This 
does not agree with the intuitive interpretation of actions. More importantly, the mapping from nat- 
ural language sentences to expressions in our calculus naturally yields a call-by-name interpretation. 



3.3 Type System 

We use type judgments to ensure that expressions are assigned types appropriately, and that the 
types themselves are well-formed. Roughly speaking, a type is well-formed if it preserves the sepa- 
ration between pure computations (computations with no side-effects) and imperative computations 
(computations that may have side-effects). The type system enforces that pure computations do 
not change the state of the application. This captures the intuition that declarative sentences — 
corresponding to pure computations — should not change the state of the world. (This correspon- 
dence between declarative sentences and pure computations is made clear in the next section.) The 
rules for the type well-formedness judgment h r ok are given in the following table, along with the 
auxiliary judgment h r pure, stating that a type r is a pure type (evaluates without side effects). 
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Judgments h r pure and h r ok: 



(Pure Obj) 


(Pure Bool) 


(Pure Fun) 


(OK Fun Pure) 


(OK Fun Act) 








h Ti pure h r2 pure 




h Obj pure 


h Bool pure 


h Ti — T2 pure 


h Ti — > T2 ok 


h r ^ Act ok 



The judgment Their assigns a type r to expression e in a well-formed environment T. 
An environment T defines the types of all variables in scope. An environment is of the form xi : 
Ti, . . . ,Xn ■ Tn, and defines each variable Xi to have type rj. We require that variables do not repeat 
in a well-formed environment. The typing rules for expressions are essentially standard, with the 
exception of the typing rule for functions, which requires that function types r ^ r' be well-formed. 

Judgment T h e : r: 

I 1 

(Typ Var) (Typ Obj) (Typ True) (Typ False) (Typ Exc) 



r,x:T\-x:T Thvo-. Oh] T h true : Bool T h false : Bool T h ★ : r 

(Typ App) (Typ Fun) 

r h ei : - ^ r' P h 63 : r T, r : r h r, : r' h r — r' ok 

FT } F^T -> ^ Dom(r)) 

1 I- ei 62 : r i h Ax:T.e : t ^ t 

(Typ If) (Typ Skip) (Typ Seq) 

Fh ei : Bool Fh 62 : r F h 63 : r F h ei : Act F h 62 : Act 



F h ei?e2:e3 : r F h skip : Act F h ei; 62 : Act 

(Typ ACon) (Typ OCon) (Typ PCon) 

F h ej : Obj G [l..n] F h : Obj e [l..n] 



F h ida(ei, ■ ■ ■ , e„) : Act F h ic/cO : Obj F h idp{ei, ... , e„) : Bool 

It is straightforward to show that our type system is sound, that is, that type-correct expressions 
do not get stuck when evaluating. We write {s, e) — >* (s', e') to mean that there exists a sequence 
(si, 62), . . . , (sn, en) such that (s, e) — > (si, ei) — > ... — > (s^, Cn) — > (s', e'). 

Theorem 3.2. If h e : t, and s is a state, then there exists a state s' and value v such that 
(s, e) — {s' , v). Moreover, ifhr pure, then s' = s. 

Proof. See Appendix A. □ 

Theorem 3.2 in fact states that the language is strongly normalizing: the evaluation of every 
expression terminates. This is a very desirable property for the language, since it will form part of 
the user interface. 

Example 3.3. Consider the following example, interpreted with respect to the appUcation model 
of Example 2.2. In state si (where both block 1 and 2 are on the table), let us trace through the 
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execution of the expression (Ax:Obj.Ay:Obj.move(a;,y)) (bl()) (b2()). (We omit the derivation 
indicating how each step is justified.) 



(si,(Ax:Obj.Ay:Obj.move(x,y)) (bl()) (b2())) 
(si,(A2/:0bj.move(bl(),y)) (b2())) 
(si,move(bl(),b2())) 
(si,move(6i,b2())) — y 
(si,move(6i,62)) — 
(s2,skip). 

In other words, evaluating the expression in state si leads to state S2, where indeed block 1 is on top 
of block 2. □ 



3.4 A Direct Interpreter 

The main reason for introducing the action calculus of this section is to provide a language in 
which to write expressions invoking procedures available in the application interface. However, 
the operational semantics given above rely on explicitly passing around the state of the application. 
This state is taken from the application model. In the model, the state is an explicit datum that enters 
the interpretation of constants, predicates and actions. Of course, in the actual application, the state 
is implicitly maintained by the application itself. Invoking an action procedure on the application 
interface modifies the current state of the application, putting the apphcation in a new state. This 
new state is not directly visible to the user. 

We can implement an interpreter based on the above operational semantics but without carrying 
around the state explicitly. To see this, observe that the state is only relevant for the evaluation of 
the primitives (constants, predicates, and actions). More importantly, it is always the current state 
of the application that is relevant, and only actions are allowed to change the state. We can therefore 
implement an interpreter by simply directly invoking the procedures in the application interface 
when the semantics tells us to reduce via 6c, 6p, or da- Furthermore, we need to be able to raise an 
exception ★ if the objects passed to the interface are not of the right class. This requires querying 
for the class of an object. As we indicated in Section 2.1, we simply assume that this can be done, 
either through language facilities (an instanceOf operator), or through exphcit procedures in the 
interface that check whether an object is of a given class. 

In summary, given an application with a suitable apphcation interface, we can write an in- 
terpreter for our action calculus that will interpret expressions by invoking procedures available 
through the application interface when appropriate. The interpreter does not require an application 
model. The model is useful to establish properties of the interpreter, and if one wants to reason 
about the execution of expressions via the above operational semantics. 



4 Categorial Grammars 

In the last section, we introduced an action calculus that lets us write expressions that can be un- 
derstood via calls to the application interface. The aim of this section is to use this action calculus 
as the target of a translation from natural language sentences. In other words, we describe a way to 
take a natural language sentence and produce a corresponding expression in our action calculus that 
captures the meaning of the sentence. Our main tool is categorial grammars. 
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Categorial grammars provide a mechanism to assign semantics to sentences in natural language 
in a compositional manner. As we shall see, we can obtain a compositional translation from natural 
language sentences into the action calculus presented in the previous section, and thus provide a 
simple natural language user interface for a given application. This section provides a brief exposi- 
tion of categorial grammars, based on Carpenter's [1997] presentation. We should note that the use 
of categorial grammars is not a requirement in our framework. Indeed, any approach to provide se- 
mantics to natural language sentences in higher-order logic, which can be viewed as a simply-typed 
A-calculus [Andrews 1986], can be adapted to our use. For instance, Moortgat's [1997] multimodal 
categorial grammars, which can handle a wider range of syntactic constructs, can also be used for 
our purposes. To simpUfy the exposition, we use the simpler categorial grammars in this paper. 

Categorial grammars were originally developed by Ajdukiewicz [1935] and Bar-Hillel [1953], 
and later generalized by Lambek [1958]. The idea behind categorial grammars is simple. We start 
with a set of categories, each category representing a grammatical function. For instance, we can 
start with the simple categories np representing noun phrases, pp representing prepositional phrases, 
s representing declarative sentences and a representing imperative sentences. Given categories A 
and B, we can form the functor categories A/B and B\A. The category A/B represents the 
category of syntactic units that take a syntactic unit of category B to their right to form a syntactic 
unit of category A. Similarly, the category B\A represents the category of syntactic units that take 
a syntactic unit of category B to their left to form a syntactic unit of category A. 

Consider some examples. If np is the category of noun phrases and s is the category of declar- 
ative sentences, then the category np\s is the category of intransitive verbs (e.g., laughs): they take 
a noun phrase on their left to form a sentence (e.g., Alice laughs or the reviewer laughs). Similarly, 
the category {np\s)/np represents the category of transitive verbs (e.g., takes): they take a noun 
phrase on their right and then a noun phrase on their left to form a sentence (e.g., Alice takes the 
doughnut). We also consider the category pp of propositional phrases, as well as the category a of 
imperative sentences. 

The main goal of categorial grammars is to provide a method of determining the well-formedness 
of natural language. A lexicon associates every word (or complex sequence of words that constitute 
a single lexical entry) with one or more categories. The approach described by Lambek [1958] is 
to prescribe a calculus of categories so that if a sequence of words can be assigned a category A 
according to the rules, then the sequence of words is deemed a well-formed syntactic unit of cate- 
gory A. Hence, a sequence of words is a well-formed noun phrase if it can be shown in the calculus 
that it has category np. As an example of reduction, we see that if a\ has category A and 02 has 
category A\B, then cri a2 has category B. Schematically, A, A\B ^ B. Moreover, this goes both 
ways, that is, if cji (J2 has category B and a\ can be shown to have category A, then we can derive 
that (72 has category A\B. 

Van Benthem [1986] showed that this calculus could be used to assign a semantics to terms by 
following the derivation of the categories. Assume that every basic category is assigned a type in 
our action calculus, through a type assignment T. A type assignment T can be extended to functor 
categories by putting T{A/B) = T{B\A) = T{B) -> r(^). The lexicon is extended so that every 
word is now associated with one or more pairs of a category A and an expression a in our action 
calculus of the appropriate type, that is, h a : T{A). 

We use the sequent notation ai : ^1 , . . . , a„ : An =^ a : ^4 to mean that expressions ai , . . . , a„ 
of categories Ai,. . . ,An can be concatenated to form an expression a of category A. We call a : A 
the conclusion of the sequent. We use capital Greek letters (S, A,...) to represent sequences of 
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expressions and categories. (We reserve T for typing contexts of the calculus in the last section.) 
We now give rules that allow us to derive new sequents from other sequents. 

Categorial Grammar Sequent Rules: 

(Seq Id) (Seq Cut) ' 
A^(3:B Ei,/3 : g,S2 ^ g : ^ 

a:A^a:A T,i, A,T,2 ^ a : A 

(Seq App Right) (Seq App Left) 

A^P-.B Si,a(/?) : ^,S2 ^7 : C A ^ P : B Ei, q(/3) : A ^2 ^ 7 : C 

Si, a : A/B, A, S2 ^ 7 : C Si, A, a : B\A, S2 ^ 7 : C 

(Seq Abs Right) (Seq Abs Left) 

T.,.r : A ^ a : B x : .1. £ => a : B 

S ^ Xx.a : B/A S ^ Xx.a : A\B 



Example 4.1. Consider the following simple lexicon, suitable for the ToyBlocks apphcation. 
The following types are associated with the basic grammatical units: 

T{np) = Obj 
T{pp) = Obj 
T{s) = Bool 
r(a) = Act. 

Here is a lexicon that captures a simple input language for ToyBlocks: 

block one bl() : np 

block two 1-^ b2() : np 

the table table() : np 

on^ (Ax:Obj.x) : pp/np 

is (Aa::Obj.Ai/:Obj.is_on(?/, a;)) : {np\s)/pp 

if ^ (Ax:Bool.Ay:Act.x?y:skip) : {a/a)/s 

move (Ax:Obj.Aj/:Obj.move(x,y)) : {a/pp)/np. 

This is a particularly simple lexicon, since every entry is assigned a single term and category. It is 
also a very speciahzed lexicon, for the purpose of illustration; our treatment of is is specific to the 
ToyBlocks example. 

Using the above lexicon, the sentence move block one on block two can be associated with the string 
of expressions and categories Aa;:Obj.Ay:Obj.move(a;, y) : {a/pp)/np, bl() : np, \x:Oh].x : 
pp/np, b2() : np. The following derivation shows that this concatenation yields an expression of 
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category a. (For reasons of space, we have elided the type annotations in A-abstractions.) 



hlQ):np =^ bl():np (f) 



Xx.Xy.move{x, y)'{a/pp)/np, bl():np, (Xx.x) (b2()):pp 



b2():np h2{):np {Xx.Xy.move{x,y)) (bl()) {{Xx.x) (b2())):a 

Xx.Xy.move{x, y)'-{a / pp) / np , bl():np, Xx.x:pp/np, b2():np 
{Xx.Xy.inove{x,y)) (bl()) ((Ax.x) (b2())):a 

where the subderivation (f) is simply: 



(t): 



(Xx.x) {h2{)):pp ^ {Xx.Xy.inove{x,y)) (bl()) {{Xx.x) (b2())):a =^ 
{Xx.x) {h2{)):pp {Xx.Xy.uiove{x,y)) (bl()) {{Xx.x) (b2())):a 

{Xx.Xy.uiove{x,y)) {hl{)):a/pp, {Xx.x) {h2{)):pp 
(Ax.Aj/.move(a;, y)) (bl()) {{Xx.x) (b2())):a. 



Hence, the sentence is a well-formed imperative sentence. Moreover, the derivation shows that the 
meaning of the sentence move block one on block two is 

(Aa;:Obj.Ay:Obj.move(x,y)) (blQ) {{Xx:Ob].x) (b2())). 

The execution of this expression, similar to the one in Example 3.3, shows that the intuitive meaning 
of the sentence is reflected by the execution of the corresponding expression. □ 

One might hope that the expressions derived through a categorial grammar derivation are always 
valid expressions of our action calculus. To ensure that this property holds, we must somewhat 
restrict the kind of categories that can appear in a derivation. Let us say that a derivation respects 
imperative structure if for every category of the form A\B or A/B that appears in the derivation, 
we have h T{A) — > T{B) ok. Intuitively, a derivation respects imperative structure if it cannot 
construct declarative sentences that depend on imperative subsentences, i.e., a declarative sentence 
cannot have any "side effects." (For the lexicon in Example 4.1, a derivation respects imperative 
structure if and only if every category of the form a\B ov B / a that appears in the derivation is 
either a\a or a/ a.) We can show that all such derivations correspond to admissible typing rules in 
the type system of the last section. (An admissible typing rule is a rule that does not add derivations 
to the type system; anything derivable using the rule can be derived without the rule.) 

Theorem 4.2. If ai : Ai, . . . , an : An ^ a : A has a derivation that respects imperative structure, 
then the rule 

rhai:r(Ai) ... Than:T{An) 
r h a : T{A) 

is an admissible typing rule. 

Proof. See Appendix A. □ 

Note that if each expression ai : Ai is taken from the lexicon, then we have h : T{Ai) by 
assumption, and therefore Theorem 4.2 says that if cti : Ai, . . . ,ak : A^ ^ a : A has a derivation 
that respects imperative structure, then h a : T{A). 
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So, given a natural language imperative sentence from the user, we use the lexicon to find the 
corresponding expressions and category pairs ai : Ai, . . . ,an : An, and then attempt to parse it, 
that is, to find a derivation for the sequent ai : Ai, . . . , an : An => a : a that respects imperative 
structure. If a unique such derivation exists, then we have an unambiguous parsing of the natural 
language imperative sentence, and moreover, the action calculus expression a is the semantics of 
the imperative sentence. 



5 Putting It All Together 

We now have the major components of our framework: a model for action-based applications and 
interfaces to them; an action calculus which can be interpreted as calls to an application interface; 
and the use of categorial grammars to create expressions in our action calculus from natural language 
sentences. 

Let's see how our framework combines these components by considering an end-to-end example 
for ToyBlocks. Suppose the user inputs the sentence move block one on block two when blocks 
1 and 2 are both on the table. Our framework would process this sentence in the following steps. 

(1) Parsing: The ToyBlocks lexicon is used to parse the sentence. Parsing succeeds only 
if there is a unique parsing of the sentence (via a derivation that respects imperative struc- 
ture), otherwise the parsing step fails, because the sentence was either ambiguous, contained 
unknown words or phrases, or was ungrammatical. In this example, there is only a single 
parsing of the sentence (as shown in Example 4.1), and the result is the following expression 
in our action calculus, which has type Act: 

(Ax:0bj.A2/:0bj.move(x,y)) (bl()) ((AxiObj.x) (b2())). 



(2) Evaluating: The action calculus expression is evaluated using a direct interpreter imple- 
menting the operational semantics of Section 3. The evaluation of the expression proceeds as 
follows. 

(si, (Ax:Obj.Ay:Obj.move(a;,y)) (bl()) ((A.T:Obj.,T) (b2()))) — > 
(si,(A2/:0bj.move(bl(),y)) ((AxiObj.x) (b2()))) 
(si,move(bl(),(Ax:Obj.x) (b2()))) — > 
(si,move(6i,(Ax:0bj.x) (b2()))) — > 
(si,move(6i,(b2()))) 
(si,move(6i,62)) — > 
(s2,skip). 

In the process of this evaluation, several calls are generated to the application interface. In 
particular, calls are made to determine the identity of the object constants bl and b2 as bi 
and 62 respectively. Then, during the last transition, guard predicates such as is_block(6i) 
and is_position(62) may be called to ensure that 61 and 62 are of the appropriate classes 
for being passed as arguments to move. Since the objects are of the appropriate classes, the 
action move(6i, 62) is invoked via the application interface, and succeeds. 
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(3) Reporting: Following the evaluation of the expression, some result must be reported back to 
the user. Our framework does not detail what information is conveyed back to the user, but 
they must be informed if an exception was raised during the evaluation of the expression. 

In this example, no exception was raised, so what to report to the user is at the discretion of 
the user interface. If the user interface had a graphical depiction of the state of ToyBlocks, 
it may now send queries to the appUcation interface to determine the new state of the world, 
and modify its graphical display appropriately. 

Let's consider what would happen if an exception (*) was raised during the evaluation phase. For 
example, consider processing the sentence move the table on block one. The parsing phase would 
succeed, as the sentence is grammatically correct. However, prior to calling the action move(t, bi), 
the evaluation would determine that the object t does not belong to the class block (by a guard 
predicate such as is_block(t) returning ff, or by some other mechanism). An exception would 
thus be raised, and some information must be reported back to the user during the reporting phase. 
Note that the framework has ensured that the action move(t, 61) was not invoked on the application 
interface. 

6 Extensions 

Several extensions to this framework are possible. There is a mismatch of types in our framework. 
The application model permits a rich notion of types: any object of the application may belong to 
one or more classes. By contrast, our action calculus has a very simple notion of types, assigning the 
type Obj to all objects, and not statically distinguishing different classes of objects. The simplicity 
of our action calculus is achieved at the cost of dynamic type checking, which ensures that actions 
and predicates on the application interface are invoked only with appropriate parameters. It would 
be straightforward to extend the action calculus with a more refined type system that includes a 
notion of subtyping, to model the application classes. Not only would this extension remove many, 
if not all, of the dynamic type checks, but it may also reduce the number of possible parses of 
natural language sentences. The refined type system allows the semantics of the lexicon entries to 
be finer-grained, and by considering these semantics, some nonsensical parses of a sentence could 
be ignored. For example, in the sentence pick up the book and the doughnut and eat it the referent 
of it could naively be either the book or the doughnut; if the semantics of eat require an object of the 
class Food and the classes of the book and the doughnut are considered, then the former possibihty 
could be ruled out. 

Another straightforward extension to the framework is to allow the user to query the state by 
entering declarative sentences and treating them as yes-no interrogative sentences. For example, 
block one is on the table? This corresponds to accepting sequents of the form ai : Ai, . . . , a„ : 
An ^ a : s, and executing the action calculus expression a, which has type Bool. The categorial 
grammar could be extended to accept other yes-no questions, such as is block two on block one? 
A more interesting extension (which would require a correspondingly more complex application 
model) is to allow hypothetical queries, such as if you move block one on block two, is block one 
on the table? This corresponds to querying is block one on the table? in the state that would result 
if the action move block one on block two were performed. This extension would bring our higher- 
order logic (that is, our action calculus) closer to dynamic logic [Groenendijk and Stokhof 1991; 
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Harel, Kozen, and Tiuryn 2000]. It is not clear, however, how to derive a direct interpreter for such 
an extended calculus. 

In Section 2.2 we made some simplifying assumptions about the application model. Chief 
among these assumptions was that an application's state changes only as a result of explicit actions. 
This assumption may be unreaUstic if, for example, the appUcation has multiple concurrent users. 
We can however extend the framework to relax this assumption. One way of relaxing it is to in- 
corporate transactions into the application model and application interface: the application model 
would guarantee that within transactions, states change only as a result of explicit actions, but if no 
transaction is in progress then states may change arbitrarily. The evaluation of an action calculus 
expression would then be wrapped in a transaction. 

Another restriction we imposed was that predicates be pure. It is of course technically possible 
to permit arbitrary state changes during the evaluation of predicates. In fact, we can modify the 
operational semantics to allow the evaluation of any expression to change states. If done properly, 
the key property is still preserved: the evaluation of constants, predicates or actions rely only on the 
current state, and all other transitions do not rely on the state at all. Thus, the semantics remains 
consistent with interpreting expressions using calls to the application interface. However, doing this 
would lose the intuitive meaning of natural language sentences that do not contain actions; they 
should not change the state of the world. 

7 Conclusion 

We have presented a framework that simplifies the creation of simple natural language user inter- 
faces for action-based appHcations. The key point of this framework is the use of a A-calculus to 
mediate access to the application. The A-calculus we define is used as a semantics for natural lan- 
guage sentences (via categorial grammars), and expressions in this calculus are executed by issuing 
calls to the application interface. The framework has a number of application-independent compo- 
nents, reducing the amount of effort required to create a simple natural language user interface for 
a given application. 

A number of applications have natural language interfaces [Winograd 1971; Price, Rilofff, 
Zachary, and Harvey 2000], but they appear to be designed specifically for the given application, 
rather than being a generic approach. A number of methodologies and frameworks exist for natural 
language interfaces for database queries (see Androutsopoulos et al. [1995] for a survey), but we 
are not aware of a framework for deriving natural language interfaces to general apphcations in a 
principled manner. 

While the framework presented here is useful for the rapid development of simple natural lan- 
guage user interfaces, the emphasis is on simple. Categorial grammars (and other techniques that 
use higher order logic as the semantics of natural language) are limited in their ability to deal with 
the wide and diverse phenomena that occur in English. For example, additional mechanisms outside 
of the categorial grammar, probably appUcation-specific, would be required to deal with discourse. 
However, categorial grammars are easily extensible, by expanding the lexicon, and many parts of 
the lexicon of a categorial grammar are reusable in different applications, making it well-suited to a 
framework for rapid development of natural language user interfaces. 

It may seem that a Umitation of our framework is that it is only suitable for applications for 
which we can provide an interface of the kind described in Section 2 — the action calculus of Sec- 
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tion 3 is specifically designed to be interpreted as calls to an action-based application. However, 
all the examples we considered can be provided with such an interface. It is especially interesting 
to note that our definition of action-based application interfaces is compatible with the notion of 
interface for XML web services [Barclay, Gray, Strand, Ekblad, and Richter 2002]. This suggests 
that it may be possible to derive a natural language interface to XML Web Services using essentially 
the approach we advocate in this paper. 
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A Proofs 

The soundness and strong normalization (Theorem 3.2) of the calculus in Section 3 can be derived 
using logical relations, in a fairly standard way [Winskel 1993]. In order to do this, we need some 
lemmas about properties of the operational semantics. 

Lemma A.l. Ifheir and {s, e) — > {s', e'), then h e' : r. 

Proof. This is a completely straightforward proof by induction on the height of the typing derivation 
for h e : T. □ 

Lemma A.2. If\- e : r, {s, e) — > {s', e'), and h r pure, then s' = s. 

Proof. This result follows essentially by examination of the operational semantics rules, proceeding 
by induction on the structure of e. 

- Case e = x: This case cannot arise, since heir cannot hold with an empty context when e 
is a variable. 

- Case e = v: An inspection of the operational semantics rules shows that this case cannot 
arise, since there is no s' and e' such that (s, e) — > {s', e') if e is a value. 

- Case e = idci)'. By (Red OCon), we have (s, e) — > {s, Sdidc)), and the state is unchanged, 
irrespectively of r. 

- Case e = idp{ei, . . . ,en): By examination of the operational semantics rules, two cases 
arise. If every is a value Vi, then (s, e) — > {s, 6p{s, idp, vi,... , Vn)), with r = Bool and 
h r pure, and the state is unchanged during the transition, as required. Otherwise, there is at 
least one that is not a value, and (s, e) — > {s, idp{. . . , e', . . . )) or (s, e) — > (s, Again, 
r = Bool, so that h r pure, and the state is unchanged during the transition, as required. 
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- Case e = ida{ei, . . . , e„): If h e : r, then r = Act, which is not a pure type, so there is 
nothing to show for this case. 

- Case e = ei 62: By examination of the operational semantics rules, two cases arise. If ei is a 
value, then it must be :*r or an abstraction Ax:r'.e'. In the former case, (s, e) — > {s, In the 
latter case, (s, e) — > {s, e'{x^e2}). In both cases, the state is unchanged, irrespectively of 
the type r. If ei is not a value, then from rule (Red App 1), we get [s, ei 62) — >■ {s, e[ 62) 
or (s, ei 62) — > (s, and the state is unchanged, irrespectively of the type r. 

- Case e = ei? 62-63: By examination of the operational semantics rules, we consider two cases. 
If ei is a value, then it must be ★ or a Boolean value. In the former case, (s, e) — > (s,*). 
In the latter case, {s, e) — > (s, 62) or (s, e) — > (s, 63), depending on whether ei is true or 
false. In both cases, the state is unchanged, irrespectively of the type r. If ei is not a value, 
then from rule (Red If 1), we get [s, e) — > {s, e'^?e2:e3) or (s, e) — > {s, and the state is 
unchanged, irrespectively of the type r. 

- Case e = ei; 62: If H e : r, then r = Act, which is not a pure type, so there is nothing to 
show for this case. 

This completes the induction. □ 

We define, for each type r, a set Rr of terms which terminate in all states. Formally, for a base 
type b, either Obj, Bool, or Act, we take 

Rb = {e\ he: t, Vs3t;3s'.(e, s) — >* {v, s')}. 

For a function type ri — > r2, we take 

Rri-^T2 = {fi I H e : Ti — >■ T2,\/s3v3s' .{6, s) — y* {v, s'), Ve' G i?7-i-(e ei) G Rt^}- 

We define a substitution operator 7 to be a partial map from variables to expressions of the 
action calculus. Let dom(7) be the domain of definition of the partial map 7. Given a context F, 
we write 7 |= F if the domains of 7 and F are equal (a context F can be understood as a partial map 
from variables to types), and for all x G dom(7), ^{x) G Rr{x)' where F(x) is the type associated 
with a; in the context F. We extend 7 to expressions, by taking 7(e) to be the expression resulting 
from replacing every variable a; in e by the expression 7(0;). Formally, 

{■j{x) if X G dom(7) 
X otherwise 
true 
false 
Xx:T.%{e) 
skip 

Vo 
-k 

idcO 



7(x) = 

7(true) = 
7(false) = 
7(Ax:r.e) = 
7(skip) = 

l{Vo) = 

7W = 
7(^40) = 
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^{idp{ei,...,en) 
j{ida{ei,...,en) 
7(ei 62) 
7(ei?e2:e3) 
7(ei;e2) 



icip(7(ei),... ,7(e„)) 
«(ia(7(ei),...,7(en)) 
7(ei) 7(62) 
7(ei)?7(e2):7(e3) 

7(ei);7(e2) 



where is the same substitution map as 7, except that it is undefined on variable x. 
Lemma A,3. IfT Heir and 7 ^ F, then h 7(e) : r. 

Proof. This is a straightforward proof by induction on the height of the typing derivation for F h e : 



Lemma A.4. If\-e:T, and for all s there exists s' and e' E Rr such that (s, e) — >* (s', e'), then 
eeRr. 

Proof. We prove this by induction on the structure of r. For a base type b, the result is immediate 

by the definition of R;,. For t = ti —>■ T2, assume \- e : ti —>■ T2, and for all s, there exists the 
required s', e'. For an arbitrary state s, let s', e' be such that (s, e) — >* (s', e'); since e' G i?T-i^T2> 
we have (s',e') — *■* for some s" and value v. Thus, (s,e) — ^* Finally, it 

remains to show that for all e" G Rr^, we have (e e") G i^^-g. By assumption, we have (e' e") G 
To apply the induction hypothesis and get (e e') G Rt2, we show that for all s, we have 
(s, e e") — >* (s, e' e"). We proceed by induction on the length of the derivation (s, e) — >* {s', e'). 
First, note that because h e : ri — > r2, which is a pure type, a straightforward induction on the 
length of the derivation using Lemma A.2 shows that s' = s. If the length is 0, then e = e', 
so the result is immediate. If the length is non-zero, then (s,e) — >* {s,e"') — > {s,e'). By 
the induction hypothesis, {s,e e") — >* {s,e"' e"). Since {s,e"') — > is,e'), by rule (Red App 
1), (s,e"' e") {s,e' e"), so that (s,e e") — >* {s,e' e"), as required. This establishes that 



We can now prove the main result. 

Theorem 3.2. If \- e : t, and s is a state, then there exists a state s' and value v such that 
{s, e) — >* {s', v). Moreover, if\- r pure, then s' = s. 

Proof. Clearly, it is sufficient to show that h e : r implies e G i?r- To use induction, we prove the 
more general statement that Their and 7 |= T implies 7(e) G Rt. (The desired result follows 
by taking 7 to be the empty substitution, and T the empty context.) We prove the general result by 
induction on the structure of e. 

- Case e = x: Assume F h a; : r, and 7 |= F. We need to show that 7(0;) G Rt. Since x 
is a variable, r = F(a;), and thus x is in the domain of F. Since 7 |= F, 7(0;) G Rt, and 
7(x) = 7(x) implies j{x) G Rt, as required. 

- Case e = true, false, skip,*, Assume F h e : 6, for the appropriate base type b, 
and 7 ^ F. We need to show that 7(e) = e G Rf,. Since e is a value, than for all s, 
{s, e) — >* {s, e), so e G Rb, as required. 



r. 



□ 



(e e") G R- 



□ 
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- Case e = \x:T.e': This is the difficult case. Assume that V h \x:T.e' : t ^ t', and 
7 ^ r. We need to show that 7(Ax:r.e') = \x:T.^{e') G Rr^r'- This involves, following 
the definition of Rt^t', establishing three facts. First, by Lemma A.3, h 7(Ax:r.e'). Since 
7(A:r.e') = Ax:.7(e') is a value, we immediately have that (s, Ax:.7(e')) reduces to a value 
for all states s. Finally, we need to show that for all e" G Rr, we have {{Xx:.j{e')) e") G i?^/. 
Given e" G Rr- By (Red App 3), for all s, (s, (Ax:r.7(e')) e") — > {s,e'{x^e"}). By 
Lemma A.4, it suffices to show that e'{x<— e"} G i?^/ to show that ((Ax:.7(e')) e") G Rr' 
(by taking s' = s). 

Define 7^ = "yx[x '-^ e"] = j[x e"] (since 7a; is just 7 expect undefined on variable x). 
Clearly, 7(e'){x<— e"} = %{e'). By assumption, we have F h Xxir.e' : t ^ t', which 
means that F, x : r h e' : r'. Now, 7^ \= T,x : t, since 7 ^ F and 7^(x) = e" G by 
assumption. Applying the induction hypothesis yields that %{e') G Rr', as required. 

- Case e = idc{)- Assume F h idd) : Obj, and 7 ^ F. We need to show that ^{idcQ) = 
idcO G -Robj- For all s, {s, idc{)) — (s, Sc{s, idc)) by (Red OCon), so idcO G i?obj' 
required. 

- Case e = idp{ei, . . . , e„): Assume F h idp{ei, . . . , e„) : Bool, and 7 ^ F. We need to show 
that 7(idp(ei, . . . ,e„)) = idp{-^{ei), . . . ,^{en)) G -RbooI- Since F \= idp(ei, . . . , e„) : 
Bool, we have F |= : Obj for all i. Applying the induction hypothesis, we get that G 
Robj for all i, and thus for all s, we can construct a derivation (s, idp{^{ei), . . . , 7(en))) — >* 
{s, idp{vi, . . . ,7(e„))) — >* ■ ■ ■ — >* (s, idp{vi, . . . ,Vn)) — > {s,dp{s,vi, . . . ,Vn)) by re- 
peated applications of (Red PCon 1) and (Red PCon 2), and a final application of (Red Peon 

3). (Alternatively, a derivation that reduces to ★ is also possible.) Therefore, idp{^{ei), . . . ,^{en)) G 
-RbooU as required. 

- Case e = ida{ei, . . . , e„): This case is exactly Uke the case for idp{ei, . . . , e^), replacing 
Bool by Act where appropriate. 

- Case e = ei 62: Assume F h ei 62 : r, and 7 |= F. We need to show that 7(61 62) = 
7(^1) 7(^2) G Rt- Since F h ei P2 : t, we know that F h ei : r' ^ r, and F h 62 : t', for 
some r'. Applying the induction hypothesis, we get 7(ei) G Rr'^r 7(^2) € -Rt'- By the 
definition of Rr'^r, we get that j(ei) 7(62) G Rr, as required. 

- Case e = ei?e2:e3: Assume F h ei?e2:e3 : r, and 7 |= F. We need to show that 
7(ei?e2:e3) = 7(ei)?7(e2):7(e3) G Rt- Since F h ei?e2:e3 : r, we know that F h ei : Obj, 
F h 62 : r, and F h 63 : r, for some r. Applying the induction hypothesis, we get 7(61) G 
-^Booh 7(^2) G Rt, and 7(63) G Rr- Therefore, for all s, we can construct either the deriva- 
tion (s,7(ei)?7(e2):7(e3)) — >* (s, true?7(e2):7(e3)) — > (.5,7(62)) — >* (s,f2)orthe 
derivation (s, 7(ei)?7(e2):7(e3)) — >* (s, false?7(e2):7(e3)) — > (5,7(63)) — >* (5,^3), 
using (Red If 1), (Red If 2), (Red If 3), depending on the Boolean value that (s, 7(61)) reduces 
to. (Alternatively, a derivation that reduces to ★ is also possible.) Therefore, 7(6i)?7(62):7(63) G 
Rr, as required. 

- Case 6 = 61; 62: Assume F h 61; 62 : Act, and 7 |= F. We need to show that 7(61; 62) = 
7(61); 7(62) G Racx- Since F h 61; 62 : Act, we know that F h 61 : Act and F h 62 : 
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Act. Applying the induction hypothesis, we get 7(61) € -Raci and 7(62) G Racx- There- 
fore, for all s, we can construct the derivation (s, 7(ei); 7(62)) — >* (s', skip; 7(62)) — > 
(s',7(e2)) — >* (s",skip), by applications of (Red Seq 1), (Red Seq 2), (Red Seq 3). (Al- 
ternatively, a derivation that reduces to ★ is also possible.) Therefore, we have 7(ei); 7(62) G 
i?Act' as required. 

If h T pure, a straightforward induction on the length of the derivation (s, e) — *■* (s', v), via 
Lemma A.2, establishes that s' = s. □ 



Theorem 4.2. Ifai : Ai, . . . ,an ■ An ^ a : A has a derivation that respects imperative structure, 
then the rule 

rhai:r(Ai) ... VVan-.T^An) 
r h a : T{A) 

is an admissible typing rule. 

Proof. We proceed by induction on the height of the derivation for ai : yli, . . . , a„ : An ^ a : A. 
First, some notation: if A is a sequence ai : ^1, . . . , a*; : and F is a typing context, we write 
r|A] for the sequence of judgments V \- a\: . . . , F h : T(^fc). For the base case, we 

have a: A^ a: A, and clearly, the typing rule 

F h a : T{A) 
F h a : T{A) 

is admissible. For the induction step, consider a number of cases, one for each possible last rule of 
the derivation. In the case (Seq Cut), the last rule of the derivation is of the form 

Si, A,S2 a: A. 
Applying the induction hypothesis, both 

riAi 



F h /? : T{B) 



and 

Fpi] ThP:T{B) FP2I 



F h a : T{A) 

are admissible typing rules. Composing these two admissible rules yields the admissible rule: 

r[Ai 

Fpi] T^p-.TiB) FP2I 



F h a : T{A). 

In the case (Seq App Right), the last rule of the derivation is of the form 

A^p:B Si,7(/3) : C,S2 ^ a : ^ 
Si,7:C/S,A,E2^a:^ 
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Applying the induction hypothesis, both 

r[Ai 

r h /? : T{B) 

and 

r h a : T{A) 

are admissible typing rules. Composing them yields the following admissible rule, upon noting that 

T{C/B) = T{B) T{C): 

riAi 

r h 7 : T{B) T{C) T h (3 : T{B) 

r[Sii rh7(^):r(c) r[S2l 

r h a : T{A). 

The case for (Seq App Left) is similar. 

Finally, in the case (Seq Abs Right), where we have a = \x.f3 and A = B/C,\he last rule of 
the derivation is of the form 

S ^ Ax./? : B/C 

Applying the induction hypothesis, for V of the form V , x : T{C), the typing rule 

T',x:T{C)hx:T{C) 
T',x:T{A)\- p -.TiB) 

is admissible. Noting that T{B/C) = T{C) T{B), in order to derive an admissible typing 
rule using (Typ Fun), we need to check that h T{C) — > T{B) ok. But this is exactly what the 
assumption that the derivation respects imperative structure gives us. We can therefore derive the 
following admissible typing rule: 



{r',x:T{C)m r',x:T{C)hx:T{C) 

r, ,r : T{C) h iJ : T{B) h T(C) T{D) ok 

r' h Xx:T{C).p : T{C) T{B). 

The case for (Seq Abs Left) is similar. □ 
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